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1 INTRODUCTION 
1.1 Document Purpose and Scope 


This document describes the concept of Flight Object, the globally 
harmonized enabler for sharing consistent flight data across air 
transportation stakeholders. It describes the development activities 
associated with the Flight Object, and it introduces the data interface 
specification proposed for the Flight Object, called the Flight Information 
Exchange Model (FIXM). 


1.2 Operational Need 

Air transportation volume is on the rise. For example, in the United States 
it is expected to almost double over the next 20 years'. To support this 
growth, flight-related data must flow more easily among all concerned 
stakeholders. This is particularly true for international flights, where data 
is exchanged among systems with dissimilar capabilities. Inconsistencies in 
how flight data is communicated and processed by these disparate systems 
leads to friction at the system interfaces. This friction is a limiting factor in 
efficient data exchanges, and it inhibits the factors that lead to air traffic 
volume increase (e.g., efficient use of resources, shorter delays, and 
decreased workloads). In addition, the quality and availability of data must 
improve to support better planning and operations. Better data consistency 
leads to increased cost-effectiveness as well as improves safety and security 
in global air transportation. 


1.2.1 Interoperability 

Today’s Air Traffic Management (ATM) systems meet their data exchange 
needs through mostly point-to-point interfaces. These interfaces are 
difficult to maintain because they do not comply (at the data level) to any 
particular standard. They are also less than reusable because data 
representation varies significantly among them. Because of the inflexible 
nature of these interfaces, pertinent data sometimes is not shared across 
domains, or the sharing requires computationally expensive and error-prone 
translation. When new interfaces are required, they are usually developed 
without the benefit of reusing the intellectual capital invested in previous 
interfaces. 


1.2.2 Semantic Harmonization 

Terminology is often inconsistent across aviation domains, and this can lead 
to miscommunication and lack of understanding. For example, various 
systems operated by the United States (U.S.) Federal Aviation 
Administration (FAA) may use different terms to describe something with 
the same meaning; Proposed-time in En Route Automation Modernization 
(ERAM), Proposed Gate Time of Departure (PGTD) in the Traffic Flow 


1 FAA National Forecast 2011-2031, February 15, 2011 
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Management System (TFMS), and Estimated Time of Departure (ETD) in 
Traffic Management Advisor (TMA) all have the same meaning. In other 
cases, data that has the same name in multiple systems may have a slightly 
different definition and usage in each of the systems. 


Reducing data friction between systems is impossible without a common 
understanding of the definition and usage of all the data elements 
exchanged in the aviation domain - a semantic harmonization among the 
stakeholders. 


1.2.3 Data Management 

Currently, flight history is usually tracked using multiple legacy and 
advanced systems across various domains. This use of technologies of 
variable capabilities can lead to degradation and inconsistencies in data 
fidelity and storage. Post-operations analysis often relies on data gathered 
from multiple sources with the potential for duplicate, missing, or 
contradictory information. (For example, data about a sensitive flight might 
be published in a surface data feed but filtered from a Traffic Flow 
Management (TFM) data feed.) Sometimes flight data comes from verbal 
accounts by pilots and controllers, often well after the fact. Being able to 
manage the lifecycle of flight data from the planning phase through the 
operational phase and well into the post-operations phase would foster a 
safer, more rapidly-responding aviation environment. 
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2 PROVIDING CONSISTENT AND UP-TO-DATE FLIGHT 
DATA - FLIGHT OBJECT 

The international aviation community is developing the Flight Object as a 

response to the challenges outlined in Section 1.2. 


2.1 The Flight Object 


The Flight Object is a complex concept that is defined by three tightly 
related entities, the Flight Object concept, the Flight Object system, and the 
Flight Object data. 


1. The Flight Object Concept. At a conceptual level, the Flight Object 
is defined as the collection of processes that allow for capturing and 
sharing the most up-to-date information about flights throughout their 
lifecycles and beyond. The Flight Object makes this information 
available to participating Air Navigation Service Providers (ANSPs), 
regulatory entities, and approved airspace users. The Flight Object 
ensures that all aviation-related systems have a consistent and 
operationally-appropriate view of flight information - including aircraft 
type, trajectory, airframe equipment, time and location estimate data, 
and other information. The Flight Object achieves operational 
improvements through such factors as higher interoperability and 
coordination, better data accuracy, increased availability of up-to-date 
flight information, consistency of flight planning and operations 
among different ATM domains, and availability of operator 
preferences and recorded history information. 


2. The Flight Object System. The Flight Object Operational Concept is 
implemented by the Flight Object System, which is a complex system 
of systems whose architecture has not yet been defined. This system 
ensures that the operational advantages postulated by the Flight 
Object Operational Concept are achieved in a manner that is 
convergent with current international modernization programs such 
as FAA’s Next Generation Air Transportation System (NextGen) and 
EUROCONTROL’s Single European Sky ATM Research (SESAR). The 
Flight Object System’s main role is to maintain a complete, consistent, 
authoritative, and up-to-date view of flight data for past, current, and 
future flights. The Flight Object System may be implemented 
differently by the different Flight Object stakeholders, but it will still 
be globally interoperable. It is currently accepted that the Flight 
Object (in general, and the Flight Object System in particular) may 
support local enhancements called for by specific characteristics of 
regional operations. 
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3. The Flight Object Data. The Flight Object Data is the collection of 
all information exchanged by the Flight Object stakeholders. It is 
composed of individual pieces of data called Flight Data Elements 
(FDEs). At the data level, the Flight Object defines the meaning and 
format of these data elements. It also defines the way data elements 
are grouped, or aggregated, in clusters. Some of these clusters have 
particular operational meaning (e.g., the Flight Plan), while others 
facilitate data management [e.g., Air Traffic Control (ATC) flight 
handoff]. The essence of the Flight Object Data is to define and 
manage the sharing of the FDEs across the multitude of Flight Object 
stakeholders, such as aircraft operators, on-board flight management 
systems, military (ATC and defense units), ANSPs, TFM, airport 
operators, flight data processing systems, law enforcement, and 
security organizations. It is currently accepted that the number and 
types of FDEs supported by the Flight Object will evolve over time 
and as the Flight Object itself evolves. 


It is recognized that while the Flight Object concept is maturing, the term 
“Flight Object” is used somewhat loosely to denote one or any combination 
of these entities. While this practice is often convenient, it is important to 
understand that the Flight Object encompasses all three aspects 
(harmonized operations, interoperable systems, and unambiguous data) 
equally. In implementation, one cannot exist without the other two. 


2.2 Flight Object as a Globally Harmonized Solution 


The Flight Object supports several global ATM initiatives which aim to 
enable advanced planning and increased efficiencies through better access 
to flight information. The Flight Object work is an international initiative 
co-developed by multiple ANSPs and regulatory bodies including the FAA, 
EUROCONTROL/SESAR, Japan Civil Aviation Bureau (JCAB), United 
Kingdom National Air Traffic Services (UK NATS), Airservices Australia, and 
NavCanada. When implemented, the Flight Object will allow seamless 
international data sharing regardless of the location, origin, or destination 
of a flight. 


2.2.1 Next Generation Air Transportation System (NextGen) 

The FAA’s NextGen program is an ongoing initiative to modernize the U.S. 
National Airspace System (NAS). Flight Object will support the NextGen 
goal of “getting the right information to the right person at the right time”? 
by increasing access and decreasing the workload required to obtain flight 
information. The availability of harmonized information through the Flight 
Object supports the System Wide Information Management’s (SWIM) goal 
of reducing point-to-point information interfaces in the NAS. NextGen is 
associated with numerous goals, called Operational Improvements (OIs). In 
particular, Operational Improvement “OI 103305: On-Demand NAS 


2 FAA, “Why NextGen Matters” 
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Information” relies on the Flight Object to ensure “NAS and aeronautical 
information is consistent across applications, and locations are available to 
authorized subscribers and equipped aircraft.”? This OI will be 
implemented in the 2018 time frame and is a key enabler to SWIM. 


2.2.2 Single European Sky ATM Research (SESAR) Master Plan 
SESAR is a joint undertaking by the European Union (EU), EUROCONTROL, 
and industry - a development effort similar to NextGen in the U.S. - to 
modernize the ATM system for Europe. The SESAR Master Plan outlines 
the path to implement the research and development actions in SESAR. A 
three-step process is used to reach the goals through Time-Based 
Operations, Trajectory-Based Operations, and Performance-Based 
Operations. One of the first steps to enabling Time-Based Operations is 
“System Interoperability with Air/Ground Data Sharing,”* which is partially 
enabled though ground-to-ground Flight Object data exchange mechanisms 
and, eventually, SWIM. 


2.2.3 ICAO Global ATM Concept 

The International Civil Aviation Organization (ICAO) has released the Global 
Air Traffic Management Operations Concept that has the vision “To achieve 
an interoperable global air traffic management system, for all users during 
all phases of flight.”° Global ANSP and user interoperability will be greatly 
advanced through use of a universal flight data exchange method and 
increased use of common semantics. The concept also supports the 
constant updating of the Flight Object to assist in flight planning, improve 
the effectiveness of Traffic Management Initiatives (TMIs), and increase the 
use of collaborative decision making (CDM). 


2.2.4 Flight and Flow Information for a Collaborative Environment 
(FF-ICE) 

The ICAO ATM Requirements and Performance Panel (ATMRPP) has 
developed a concept known as Flight and Flow Information for a 
Collaborative Environment (FF-ICE) that advances the sharing of, and 
mechanisms for sharing, airspace users’ flight information, user 
preferences, search and rescue information, and access requirements.°® FF- 
ICE supports the collaborative environment envisioned in ICAO’s Global Air 
Traffic Management Operations Concept. The Flight Object will help meet 
these concept goals through increased access to existing flight information. 
While the FF-ICE does not mandate a specific flight object data model, it 


3 FAA NextGen Implementation Plan, 2012 
4 SESAR European ATM Master Plan, 2012 
5 Global Air Traffic Management Operational Concept 


8 Manual on Flight and Flow Information for a Collaborative Environment 
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does support the communication of flight and flow information among ATM 
stakeholders. 
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3 EXCHANGING FLIGHT OBJECT DATA - FIXM 

The Flight Object achieves its global interoperability and harmonization 
goals through (among other things) a data specification called the Flight 
Information Exchange Model (FIXM). 


3.1 FIXM 


FIXM is an extensible markup language (XML) data interchange format 
used to communicate FDEs contained in the Flight Object’. It is a set of 
rules that define the language, format, and relationships of how flight 
information will be exchanged. FIXM serves as the means for airspace 
users and aviation-related systems to understand the meaning of the FDEs 
and the format in which they are expressed. 


It should be noted that although the terms are sometimes used 
interchangeably, FIXM and the Flight Object are separate entities. FIXM is 
a data exchange specification (an XML schema) that facilitates the sharing 
of flight-related information. It is envisioned that FIXM will be used as the 
principal (possibly only) data interface of the Flight Object. This, however, 
does not preclude near- and mid-term systems from using FIXM - 
independently from the Flight Object - as a general-purpose, globally 
harmonized, modern interface that is compatible with service-oriented 
architectures such as FAA’s SWIM. 


FIXM has three major components (all of which are available at 
www.fixm.aero): 


1. An XML schema that facilitates the building of data interfaces for 
exchanging a predefined set of FDEs. 

2. A Unified Modeling Language (UML) data model that depicts the 
FDEs, their properties, and their relationships. This package includes 
a conceptual data model as well as a logical data model. 

3. A Data Dictionary that captures the meaning and usage rules for the 
included FDEs. For each FDE listed in the FIXM Data Dictionary, the 
following information is included: definition of the FDE, alternate 
names that reflect various nomenclatures across systems and 
domains, hierarchical relationships among the existing FDEs, data 
types, value ranges (where applicable), business rules associated with 
the individual use of each FDE, additional notes regarding the FDE, 


7 While the FDE content of the Flight Object is not currently defined, there is an 
understanding that the FDEs most commonly used in the current exchanges among 
aviation systems will become - de facto - part of the Flight Object. FIXM contains a globally 
harmonized collection of such FDEs. More information can be found at www.fixm.aero. 
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and references to authoritative documents from which these FDEs are 
derived. 


It is important to understand that the FDEs defined by the FIXM 
development effort (see Section 3.2) will one day be part of the flight 
information managed by the Flight Object. For now, the FDEs can be used 
(through the FIXM specification) to implement any flight information data 
interface, independently from the Flight Object. 


FIXM is part of a family of technology-independent, harmonized, and 
interoperable information exchange models and XML schemas. It is 
designed to interoperate with the following aviation data standards: 


e The Aeronautical Information Exchange Model (AIXM) enables the 
management and distribution of Aeronautical Information Services 
(AIS) data in digital format. Additional information is found at 
http://www.aixm.aero. 

e The Weather Information Exchange Model (WXXM) enables a 
platform-independent, harmonized, and interoperable meteorological 
information exchange covering all the needs of the air transport 
industry. Additional information is found at http://www.wxxm.aero/. 


3.2 FIXM Development 


FIXM is currently being developed collaboratively by a multinational, 
interdisciplinary team. Based on the experience of legacy interfaces, new 
concepts such as Flight Object Interoperability Specification (ED-133) and 
FF-ICE, and existing standards such as Procedures for Air Navigation 
Services and Air Traffic Management (ICAO 4444), the FIXM team is 
systematically developing the definitions and modular representations of 
the FDEs that will become part of the Flight Object. 


3.2.1 FIXM Technical Review Board 

A FIXM Technical Review Board has been established to identify candidate 
FDEs for the Flight Object, develop a Data Dictionary to describe the FDEs, 
develop a FIXM XML schema, solidify the operational concept for Flight 
Object, identify issues related to the use of FIXM, and suggest resolutions. 
The FIXM Technical Review Board is comprised of members of the FAA, 
several other ANSPs (EUROCONTROL, Airservices Australia, NATS UK, 
JCAB), and industry. 


3.2.2 FIXM Releases 

FIXM version 1.0 was released in August 2012. This release is associated 
with the exchange of data in the ICAO 2012 Flight Plan and the Globally 
Unique Flight Identifier (GUFI). In December 2012, FIXM version 1.1 was 
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released; it added the exchange of information associated with transporting 
hazardous air cargo. FIXM version 2.0 is scheduled for release in 2013. It 
will include all of FIXM 1.1 with the additional FDEs that appear in Air 
Traffic Services (ATS) messages, ATS Interfacility Data Communications 
(AIDC) messages, Traffic Flow Management Data Exchange (TFMDE), 
FAA/Airservices Australia CDM, Fleet Prioritization, Flight Data Processing 
System (FDPS), ANSP-ANSP boundary crossings, Airport Surface Detection 
Equipment - Model X (ASDE-X), Aircraft Situational Display to Industry 
(ASDI)/Flight Training Manual (FTM) connect, Add Code Share, and Airport 
CDM. Each FIXM release includes a logical data model, an XML schema, 
and a Data Dictionary. 


3.2.3 Demonstrations 

A series of demonstrations is being planned by the FAA, EUROCONTROL, 
and Airservices Australia to test various aspects of the FIXM concept, 
illustrate potential benefits of FIXM, and identify challenges and issues in 
implementing FIXM. Three FIXM demonstrations have been conducted 
thus far and have successfully shown the following: 


e Flight Object exchange between oceanic ATC systems (U.S. and 
Portugal) across the Atlantic Ocean 
e Potential benefits by enabling Flight Object exchange among Atlantic- 
based airport surface stakeholders, ANSP entities, and flight 
operators 
e Gate-to-gate scenarios involving Pacific-based surface, en route, and 
oceanic systems, as well as some simulated future Flight Object- 
enabled systems. The scenarios illustrated the following concepts: 
o Real-time exchange of hazardous cargo information between 
airlines and airports 
o Ability for airlines to view in real-time their flight sequences 
with assigned priorities 
Oo More efficient coordination in an oceanic conflict situation 


FIXM demonstrations are being conducted on the NextGen Test Bed in 
Daytona, Florida. The demonstrations also illustrate the use of SWIM core 
services in the exchange of flight data. The next scheduled FIXM 
demonstration will emphasize a “mini-global” environment that will build on 
the previous Atlantic and Pacific demonstrations. Additional information 
about the FIXM demonstrations can be found at http://www.fixm.aero. 
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4 FLIGHT OBJECT OVERVIEW 


4.1 Operational Concept Overview 
This section provides an overview of the operational concept of the Flight 
Object. 


4.1.1 High Level Architecture 

Today, when aviation automation systems (such as the ATC systems of two 
ANSPs) require an exchange of flight data, system owners agree on the 
method of transmission, data formats, frequency of transmission, and other 
details which are then specified in Interface Requirements Documents 
(IRDs) and Interface Control Documents (ICDs) for the two systems. Adding 
a new interface - or modifying existing ones - is costly and complex. In 
many cases, systems maintain different data sets of semantically equivalent 
information about the same flight, resulting in information segmentation. 
Furthermore, because these systems often name the same data elements 
differently and represent them differently, a translation layer is required for 
these systems to communicate. Figure 3-1 illustrates the flight data 
communication situation today. 


Today 


Existing systems communication 
structure 


En Route Data 


baieie Terminal 

adar Data Data 
Traffic Flow Inter 
Management Agency 


Aeronautical 
Information 


Figure 4-1: Point-to-Point Exchange of Flight Data among Current 
Air Traffic Systems? 


8 Picture is courtesy of the John A. Volpe National Transportation Systems Center. 
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In the Flight Object concept, such flight data no longer need to be sent 
system to system according to the protocol specified in their ICDs. Instead, 
flight data are available from a single resource. There is no need to 
arbitrate among different sources of the data - the Flight Object contains 
the authoritative value for each exchanged FDE. The Flight Object is 
updated in real-time by data derived from any number of systems - 
including ATC systems, airspace user fight planning systems, on-board 
avionics, and airport automation systems - and according to established 
rules followed by all data providers. The data in the Flight Object are also 
time-stamped so that the user of the data can ascertain when the most 
recent update to the data occurred. Figure 2-2 illustrates the flight data 
exchange among flight data users and providers in the Flight Object 
concept. 


Enterprise Management 


Secure access points for NAS systems 
and data sharing 


Figure 4-2: Flight Data Exchange in the Flight Object Concept® 


There are several kinds of data associated with a flight, some of which 
remain internal to the system or organization that produces the data. 
Currently, it is envisioned that only the flight data that are exchanged with 
other systems are placed in a Flight Object. For example, data in which 
only the air carrier has an interest, such as proprietary data, need not be 
managed by the Flight Object. 


While the implementation details of the Flight Object are not yet defined, 
the following notional example may be useful to illustrate how the Flight 


° Picture is courtesy of the John A. Volpe National Transportation Systems Center. 
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Object could exchange data. Accessing the data in the Flight Object is 
coordinated through a subscription service - that is, if an automation system 
has need of specific data about the flight, it subscribes to the Flight Object 
for that flight. This entitles that system to retrieve or update FDE values 
from the Flight Object at any time during (and after) the flight’s duration. 
Rules to enable or disable a system to update an FDE are determined when 
the Flight Object is created. 


4.1.2 Users of the Flight Object 

There are many potential users and uses of the data in a Flight Object. 
Typical users of Flight Object data (and their areas of interest) include the 
following: 


e Airspace users 
o Flight planning 
o Flight following 
o Air carrier network planners 
o Aircraft maintenance 
e ANSPs 
o ATC 
« Aircraft separation 
« Flight plan processing 
« Flight following 


« Understanding demand over time of NAS resources 
« Understanding capacity over time of NAS resources 
" Developing effective TMIs 
» “What-if” analyses 
« Notification of airspace and airport constraints 
«" Notification of planned or active TMIs 
e Airports 
o Ground services (e.g., airplane turnaround activities, catering, 
baggage handling) 
o Gate management 
o Ramp control 
o De-icing services 
e Airspace security 
o Identification of flights carrying hazardous cargo 
o Rapid coordination in event of security situation 
e Airspace Analysts 
o Post-operations analysis 
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o Improvement of development and execution of TMIs 


4.1.3 Notional Example: Overview of the Flight Object for a Nominal 
Flight 

This section illustrates possible activities and their associated flight data 
that are exchanged with the Flight Object for a nominal flight. This 
example is notional, because specific details on roles and responsibilities, 
rules, implementation of the Flight Object, and so forth are dependent on 
system architecture and have not been finalized. 


The Flight Object defines a flight as an aircraft trip taking off at a departure 
aerodrome and landing at the arrival aerodrome’’. (In other contexts, this 
might be considered a “flight leg.”) Thus, a single airframe may experience 
multiple flights on any given day, and a passenger who boards that aircraft 
may travel on multiple flights before arriving at the passenger’s final 
destination. 


4.1.3.1 Pre-Departure 
As soon as an airspace user chooses to publish data about its schedule or 


make details about a flight known to others, a unique identifier for the 
flight, called a Globally Unique Flight Identifier (GUFI), is assigned. The 
GUFI permanently associates a flight with all of its corresponding FDEs. 


Airspace users gather information about conditions of the NAS and other 
Flight Information Regions (FIRs) to plan their flights. Users factor in their 
crew and airframe availability, weather predictions, and their network 
operation objectives for the day. At this point, they develop early intent 
flight plans whose information is communicated to the Flight Object. 


Such data as the following may be entered initially by the airspace user into 
the Flight Object and may be updated several times by the airspace user or 
other systems before the flight’s departure: 


e Aircraft identification 

e Departure time estimate 

e Arrival time estimate 

e Route 

e Aircraft capabilities (e.g., navigation, communication, equipage to fly 
over water, self-separation) 


10 This is a simplified definition for the purposes of illustration. The Flight Object notion of 
flight contains information from gate to gate. (It includes pre-takeoff and post-landing 
surface movement, for example.) 
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e Departure prioritization of an airline’s flights from a given airport 


4,1.3.2 Departure 
As the aircraft nears departure time, details about the departure become 


more clear. Airspace users continuously monitor their network of 
operations, noting delays, as well as crew and aircraft availability, and 
update the Flight Objects as necessary. Ground services and other airport 
crew plan their resources around departure and gate information available 
in the Flight Object. Tower and terminal systems monitor their demand 
estimates with Flight Object data. 


The airspace user, tower automation, or other ATC automation may enter, 
update, or use these typical flight data in the Flight Object: 


e Departure time 

e Arrival time estimate 

e Route 

e Departure gate 

e Fuel on board 

e Aircraft weight 

¢ Minimum Equipment List (MEL) 

e Passenger information (e.g., count) 

¢ Cargo information (e.g., contents of hazardous cargo) 

e¢ Controlled time of departure, in the case of airport ground delays 
e Runway and taxiway preferences 

e Departure prioritization of an airline’s fleet from a given airport 


4.1.3.3 En Route 
In the en route phase of flight, the data in the Flight Object are updated 


frequently by ATC automation and on-board avionics. The airspace user can 
monitor flight progress and performance using data contained in the Flight 
Object. Downstream automation systems (e.g., en route or arrival) monitor 
demand for their resources using data from the Flight Object. When 
controlled times are required to manage airspace or airport constraints, 
coordination of airspace user preferences can be facilitated via the Flight 
Object. Additionally, if a security event were to arise, authorities could 
access the information about the flights of interest - through the Flight 
Object - to assess the situation and plan appropriate courses of action. 


Typical Flight Object data that may be updated or used while the aircraft is 
en route include the following: 
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e Arrival time estimate 

e Route 

e Fuel on board 

e Fix arrival times 

e Airspace user preferences for fleet prioritization for en route 
resources 

e Other airspace user preferences (e.g., cruise level, reroute 
preferences) 

¢ Controlled time of arrival (CTA) to an airspace experiencing a 
Capacity constraint 

e Information about critical situations that have developed on board 
(e.g., passenger requiring medical services, security situation, 
maintenance issues) 


4,1.3.4 Arrival 

As the aircraft nears the arrival airport, information in the Flight Object is 
used to plan ground services and resources at the airport arrival gate. If an 
airline finds that an airframe unexpectedly becomes unavailable for service, 
it must adjust its network objectives for the day, amend its schedule, and re- 
plan its resources accordingly. These changes can be communicated to 
others via the Flight Object. 


Typical flight data updated or used in the Flight Object during the arrival 
phase of flight include the following: 


e Arrival time 

e Fuel on board 

¢ Route 

e Arrival gate 

e Airspace user preferences about fleet prioritization for arrival fixes or 
aerodrome resources 

e Other airspace user preferences (e.g., runways, taxiways, gates) 


4.2 Key Concepts 

While aviation has never been safer, it is recognized that improvements in 
storing, accessing, and communicating information about a flight are 
needed. The concept of a Flight Object has been recognized for many 
years, not just by the U.S. NAS but by other FIRs as well. While research 
and engineering continue to better define the Flight Object, rules of use, 
roles and responsibilities, and architecture considerations, and important 
ideas have been guiding research efforts about the Flight Object. This 
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section discusses those key ideas. Information about engineering analyses 
for these Flight Object concepts can be found at http://www.fixm.aero. 


4.2.1 Single Resource for Exchanged Flight Data 

When the Flight Object is implemented, the exchange of flight data will be 
more easily facilitated because there will be a single authoritative source 
for all of the data pertaining to a single flight. Having flight data accessible 
from a single source and through a common infrastructure will do the 
following: 


e Make it easier to access flight data 

e Control access 

e Ensure a consistent format of the data and consistent meaning; 
remove ambiguity 

e Provide a single picture of flight intent and activity 

e Standardize rules for data access 

e Remove redundancy of data 

e Simplify data processing 

e Facilitate post-operations analysis 


4.2.2 Globally Unique Flight Identifier (GUFI) 

The GUFI is assigned as soon as exchange of a flight’s data with other 
systems is needed - for example, at flight plan filing - and remains the 
unique identifier for that flight. Whenever subsequent transactions for the 
flight are made, the GUFI is included in the transaction. The GUFI is 
associated with the flight forever and, once assigned, is never reused. The 
GUFI is recognized as the unique identifier across all FIRs and by all 
ANSPs. The GUFI concept is important because it addresses the current 
issue of correlating data from different sources, such as the Official Airline 
Guide (OAG), airspace user flight plans, and flight plans from other ANSPs. 
More information about the GUFI proposed to be used by the Flight Object 
can be found at http://www.fixm.aero. 


4.2.3 FIXM Core vs. Extension 

All ANSPs have the need to update a common set of data about each flight. 
Because ANSPs have unique challenges and issues in their airspace, there 
may be additional flight data that are of interest to some ANSPs but not to 
others. In FIXM, the concept of Core and Extension has been introduced. 
The FIXM Core contains the flight data that all participating ANSPs are 
required to send and receive. In addition, ANSPs may establish FIXM 
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extensions for data unique to their operation. FIXM will be designed so that 
a system can retrieve data seamlessly from either FIXM Core or Extensions. 


An open-source process will be established to register, test, and evaluate 
FIXM extensions. 


4.2.5 Transition to Flight Object 

Not all users of flight data will be able to immediately transition their 
automation systems and processes to be Flight Object-compliant. ANSP 
automation will accommodate both Flight Object users and non-Flight 
Object users. Each aviation system would most likely continue to maintain 
a legacy method and a Flight Object method for exchanging flight 
information for an indefinite time. 
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9 BENEFITS OF FLIGHT OBJECT 


To be successful, the Flight Object must provide real benefits in the 
planning, operational, and post-operational phases of the flight. The 
benefits are closely correlated with the operational needs outlined in 
Section 1. While some of the operational needs could be addressed through 
other means, it is widely recognized that the Flight Object provides a 
flexible solution that is aligned with the long-term growth, safety, and 
efficiency goals of ANSPs. The Flight Object is technically compatible with 
the architectures proposed by SESAR and NextGen, and with the principles 
of modern high-availability data exchange architectures. 


5.1 Interoperability 
The Flight Object ensures interoperability on multiple levels. 


1. Data Discovery. The Flight Object allows systems to discover flight- 
related data and subscribe to it. This means that once an interface to 
the Flight Object is established, the types of data consumed through 
that interface can be augmented with relative ease. 

2. Standardized Interfaces. The interfaces to the Flight Object are 
standardized both at the data definition level (the FIXM level) and at 
the physical interface level (currently thought to be a SWIM-compliant 
interface). This standardization allows stakeholders to deploy new 
systems faster and less expensively. 

3. Higher Throughput. The Flight Object interfaces will support 
scalable throughput and will have quality of service controls. They 
will rely on a separately developed infrastructure (SWIM) for data 
exchange services - this means that systems will be able to reuse 
interface strategies and services. 

4. Unambiguous Data. A single globally unique identifier for each 
flight used by all aviation systems ensures consistency of flight 
information and reduces ambiguity. The need for human intervention 
decreases, thus saving operational cost and time. The GUFI simplifies 
the data archiving process and allows for the recovery of data that 
may have been lost due to a variety of reasons. 

5. Flexibility of the Exchange Model and Schema. A modular 
construct allows for the expansion of FDEs. FIXM provides for growth 
and flexibility that are required to support evolving NextGen 
programs and automation systems, as well as data exchanges with 
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international stakeholders. FIXM removes the need to develop 
additional IRDs and ICDs for each new aviation system, thus saving 
development cost. (For example, the entire set of FDEs associated 
with Hazardous Cargo was added to FIXM without the need to amend 
other unrelated FDEs.) 


5.2 Harmonization 

The Flight Object combines the institutional knowledge of aviation 
stakeholders around the world to standardize the meaning of flight data and 
how this data is used across systems, agencies, and various countries. This 
is a huge benefit to the aviation community, because it provides 
stakeholders with common naming, meaning, and data representations for 
flight data. This eliminates the misinterpretation of information that can 
lead to performance degradation (e.g., due to incorrect demand/capacity 
predictions) and potential safety impacts. As a result, operational efficiency 
is improved. 


The harmonized vocabulary provided by the Flight Object attempts to 
eliminate the need for data translation, which is both slow and error-prone. 
It also reduces data duplication by ensuring that synonyms are eliminated - 
that is, systems will not exchange the same data under multiple names. 
This consolidation has significant performance implications through data 
volume reduction. 


5.3 Data Management 

The Flight Object allows stakeholders to have a holistic view of the flight’s 
lifecycle. The GUFI enables more precise post-operations analysis than 
previously possible. Airspace users can better communicate with ANSPs 
their long-term flight intent, and they can more precisely account for flights 
that are cancelled or whose schedule is changed significantly. 


The Flight Object allows aggregation of data that has previously been very 
difficult - sometimes impossible - to achieve. Through data mining, all 
stakeholders will be able to gain deeper insight into how the airspace is 
used, identify systemic inefficiencies that are not currently apparent, and 
develop better ways of optimizing airspace for the air traffic of the future. 
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APPENDIX A: LIST OF ACRONYMS AND ABBREVIATIONS 


Acronym or 
Abbreviation 


AIDC 
AIS 
AIXM 
ANSP 
ASDE-X 
ASDI 
ATC 
AT™ 
ATMRPP 
ATS 


CDM 
CTA 


DAL 


ERAM 
ETD 
EU 


EUROCONTROL 


Definition 


ATS Interfacility Data Communications 
Aeronautical Information Services 
Aeronautical Information Exchange Model 

Air Navigation Service Provider 

Airport Surface Detection Equipment - Model X 
Aircraft Situational Display to Industry 

Air Traffic Control 

Air Traffic Management 

ATM Requirements and Performance Panel 

Air Traffic Services 


Collaborative Decision Making 
Controlled Time of Arrival 


Delta Air Lines 


En Route Automation Modernization 
Estimated Time of Departure 

European Union 

European Organisation for the Safety of Air 
Navigation 


Federal Aviation Administration 

Flight Data Element 

Flight Data Processing System 

Flight and Flow Information for a Collaborative 
Environment 

Flight Information Region 

Flight Information Exchange Model 

Flight Management System 

Flight Operations Center 

Flight Training Manual 


Globally Unique Flight Identifier 


Page 27 


N90 
NAS 
NATS 
NextGen 


OAG 
OI 
ORD 


PGTD 


SESAR 


STAR 
SWIM 


TFM 
TFMDE 
TFMS 
TMA 
TMI 
TRACON 


International Civil Aviation Organization 
Interface Control Document 
Interface Requirements Document 


Japan Civil Aviation Bureau 
John F. Kennedy International Airport 


Los Angeles International Airport 


Madrid Barajas Airport 
Minimum Equipment List 


New York TRACON 

National Airspace System 

National Air Traffic Services 

Next Generation Air Transportation System 


Official Airline Guide 
Operational Improvement 
Chicago O’Hare International Airport 


Proposed Gate Time of Departure 


Single European Sky Air Traffic Management 
Research 

Standard Terminal Arrival Route 

System Wide Information Management System 


Traffic Flow Management 

Traffic Flow Management Data Exchange 
Traffic Flow Management System 

Traffic Management Advisor 

Traffic Management Initiative 

Terminal Radar Approach Control 


United Kingdom 

Unified Modeling Language 
United States 

Coordinated Universal Time 
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WXXM Weather Information Exchange Model 


XML Extensible Markup Language 


APPENDIX B: OPERATIONAL SCENARIO 


B.1 Scenario: Nominal International Flight Using Flight Object 
This section illustrates how a Flight Object is initiated and updated as an 
aircraft follows its path to its destination. In this scenario, the aircraft 
begins its journey at Chicago O’Hare International Airport (ORD), lands at 
John F. Kennedy International Airport (JFK) in New York City to accept 
additional passengers, then continues to its final destination, Madrid 
Barajas Airport (MAD) in Spain - a total of two flights (from the Flight 
Object concept’s point of view). Along the way, the aircraft traverses 
several facilities within the NAS and several FIRs, each updating the 
respective Flight Object for the two flights. Times in this scenario are 
indicated for illustrative purposes only, and are expressed in Coordinated 
Universal Time (UTC). Additionally, although the roles and responsibilities, 
and rules for updating the Flight Object are not known at this time, they are 
postulated in this scenario to illustrate key aspects of the Flight Object. 


Scenario: 

May 1 Delta Air Lines (DAL) files a flight plan for its aircraft, 
whose tail number is N1234, with the following 
itinerary: 

e The aircraft begins as flight DAL3288 departing 
ORD at 20:45 Saturday, May 4, and arriving at 
JFK at 22:58 

e The aircraft departs JFK with a different flight 
number, DALOO003, at 00:15 Sunday, May 5, and 
is scheduled to arrive at MAD at 06:35 on May 5 

May 1 A GUFT is assigned to each of DAL 3288 and DALO0003 
for their departures on May 4 and 5, respectively. 

May 4, Delta’s system populates the Flight Object of each of 

00:00 the flights with their flight data, including the 
assigned GUFIs. 

May 4, DAL3288 departs ORD as scheduled. 

20:45 
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May 4, 
21:30 


May 4, 
22:40 


May 4, 
22:50 


May 4, 
23:32 
May 4, 
23:47 


May 4, 
23:05 


A thunderstorm develops in en route airspace; 
DAL3288 is given a reroute by TFM. The rerouting 
causes the flight to be behind its schedule by 10 
minutes. The enroute center automation updates the 
Flight Object with the route information and revised 
times for fix crossing, runway, and gate arrival. 


Delta Air Lines has been monitoring the situation and 
continually adjusts its fleet prioritization at key 
resources in the NAS, entering fleet prioritization 
information into the Flight Object of its affected 
flights. In particular, DAL 3288 is given higher 
priority over other flights in its fleet that are arriving 
at JFK within 15 minutes of DAL 3288. 


Traffic Flow Managers consult Delta’s fleet 
prioritization specification as flights approach 
constrained fixes, and, whenever possible, attempt to 
satisfy the prioritizations indicated. 


After DAL 3288 enters New York Terminal Radar 
Approach Control (TRACON) (N90) airspace, the wind 
direction at the airport shifts from north to south. All 
arrivals to JFK are rerouted to the northern approach 
fix, resulting in an additional 15-minute delay for DAL 
3288. 


The Flight Object FDE, Arrival Time-Actual, is updated 
to 23:32. The pilot inputs the Standard Terminal 
Arrival Route (STAR) approach into the Flight 
Management System (FMS), including assigned 
runway 13R. The Flight Object FDE, Arrival Runway, 
is updated. 


DAL 3288 arrives at JFK 


DALO0003’s departure time is delayed by10 minutes. 
Its Flight Object FDE, Departure Time-Estimated, is 
updated to 00:25. 


Automation systems monitoring the NAS have 
immediate access to the updated arrival and 
departure information. 


Another aircraft in the Delta fleet, DALO087, is 
scheduled to depart JFK at 00:25 on May 5, arriving at 
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May 5, 
00:25 


May 5, 
00:25-06:35 


May 5, 
06:35 


Los Angeles International Airport (LAX) at 06:50. DAL 
0087 is already positioned at JFK. 


Following the Delta fleet prioritization, DALO087 
incurs a departure delay to allow DALO003 to depart 
at its revised departure time of 00:25. The following 
FDEs are updated in the respective Flight Objects: 


DALO003: Departure Time-Actual to 00:25 
DAL0087: Departure Time-Actual to 00:33 


DALO0003 departs JFK. The Flight Object is updated 
with the actual time of departure. 


Wind conditions are such that DALO0003 flies a 
southern route in the North Atlantic Tracks from JFK 
to MAD. The pilot inputs the assigned track into the 
FMS. The Flight Object FDE, Route, is updated. 


DALO03 flies its planned route through New York 
Center airspace, Santa Maria Oceanic FIR (controlled 
by Portugal), and finally to Madrid’s terminal 
approach control airspace. The Flight Object is 
updated throughout its flight. 


DALOO3 arrives at MAD. The Flight Object is updated 
with actual arrival runway, actual runway arrival time, 
and actual gate arrival time. 


Figure B-1 illustrates DAL 3288’s and DALOO3’s flight paths in the NAS and 
across the Atlantic Ocean. 
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Figure B-1: Ground Track for DAL0003"! 


B.2 The Flight Object in a Flight’s Life Cycle 

This operational scenario illustrates the ease of access to and exchange of 
information that will be available through the Flight Object. This scenario 
was developed under the following assumptions: data communication is 
available and widely used by aircraft; decision support and collaboration 
tools provide common situational awareness among ANSP, airspace users, 
and operators; arrival, departure and surface management tools are 
available and fielded; and policies are in place for secure information data 
sharing access and exchange between net-centric environments. 


In today’s air traffic environment, controllers and ATC systems manage and 
interact with a flight throughout its duration, from pre-flight checks to 
arrival at the gate. Depending on the aircraft’s on-board technology, flight 
information needed by ATC to manage the aircraft must be obtained via 
voice communications with the pilot. Such verbal communication is a 
possible source of error and also contributes to radio frequency congestion. 
For example, if a pilot requests a diversion to a new destination due to 
mechanical error or a system constraint, the request is conducted via voice 
communication, and this information is then relayed verbally to all other 
ATCs that will manage the flight. Additionally, flight information such as 
assigned speed or heading must be coordinated verbally among ATC sectors 
and facilities. 


11 Picture is courtesy of North Atlantic MNPS Airspace Operations Manual, 2008. 
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Through the Flight Object, a wealth of information can be exchanged among 
ANSPs, the aircraft, the Flight Operations Center (FOC) and other 
applicable parties. Information - such as assigned airspeed, climb/descent 
rate and heading; aircraft and pilot capabilities; fleet prioritization and user 
preferences; arrival and departure runway, terminal and gate assignment, 
as well as the scheduled, actual, and estimated times at those points - is 
exchanged and updated via the Flight Object. 


Prior to departure, aircraft operators file a flight plan which is assessed 
against existing, planned, and forecast constraints. Flight plan revisions 
can be negotiated and revised pre- and post-departure to mitigate those 
constraints. This information will be updated in the Flight Object 
immediately and provided to air traffic controllers who will manage the 
aircraft later in its flight. Any change to flight data that occurs before and 
during a flight is captured and updated through the Flight Object. 
Departure and enroute information, flight intent and user preferences, 
aircraft performance and wake turbulence data, aircraft and pilot 
capabilities, and traffic management constraints and initiatives are kept up- 
to-date in the Flight Object. Sharing flight information contained within the 
Flight Object in an agreed terminology and format, will improve the 
accuracy of information updates, trajectory modeling and decision making, 
consistency of flight information, and transition of flights between different 
domains. 
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